Many storage networks may implement data replication and/or other redundancy data access techniques for data loss protection and non-disruptive client access. For example, a first storage cluster may comprise a first storage controller configured to provide clients with primary access to data stored within a first storage device and/or other storage devices. A second storage cluster may comprise a second storage controller configured to provide clients with primary access to data stored within a second storage device and/or other storage devices. The first storage controller and the second storage controller may be configured according to a disaster recovery relationship, such that the second storage controller may provide failover access to replicated data that was replicated from the first storage device to a secondary storage device, owned by the first storage controller, but accessible to the second storage controller (e.g., a switchover operation may be performed where the second storage controller assumes ownership of the secondary storage device and/or other storage devices previously owned by the first storage controller so that the second storage controller may provide clients with failover access to replicated data within such storage devices).
In an example, the second storage cluster may be located at a remote site to the first storage cluster (e.g., storage clusters may be located in different buildings, cities, thousands of kilometers from one another, etc.). Thus, if a disaster occurs at a site of a storage cluster, then a surviving storage cluster may remain unaffected by the disaster (e.g., a power outage of a building hosting the first storage cluster may not affect a second building hosting the second storage cluster in a different city).
In an example, two storage controllers within a storage cluster may be configured according to a high availability configuration, such as where the two storage controllers are locally connected to one another and/or to the same storage devices. In this way, when a storage controller fails, then a high availability partner storage controller can quickly takeover for the failed storage controller due to the local connectivity. Thus, the high availability partner storage controller may provide clients with access to data previously accessible through the failed storage controller.
Various replication and synchronization techniques may be used to replicate data (e.g., client data), configuration data (e.g., a size of a volume, a name of a volume, etc.), and/or write caching data (e.g., cached write operations) between storage controllers and/or storage devices. In an example of synchronization, a synchronous replication relationship may be implemented between the first storage controller and the second storage controller, such that an incoming write operation to the first storage controller is locally implemented upon a first consistency group (e.g., one or more files, logical unit number (LUNs), LUNs spanning multiple volumes, or any other type of storage object) by the first storage controller and remotely implemented upon a second consistency group (e.g., maintained as a backup replication of the first consistency group) by the second storage controller before an acknowledgement is provided back to a client that sent the incoming write operation. In an example of replication, snapshots of the first consistency group may be used to replicate the first consistency group to the second consistency group. For example, a base snapshot of the first consistency group (e.g., a volume comprising the first consistency group) may be used to initially create the second consistency group. A current incremental snapshot of the first consistency group (e.g., the volume) may be used to replicate changes made to the first consistency group since the base snapshot or since a last incremental snapshot. Snapshots may also be periodically created and used to recover from operational failures or corruption. Unfortunately, snapshot creation may be disruptive to client access to the first consistency group (e.g., client write requests may be blocked during snapshot creation) and/or may be disruptive to the synchronous replication relationship (e.g., if client write operations are not blocked and are implemented upon the first consistency group while a snapshot of the second consistency group is being created, then data divergence between the first consistency group and the second consistency group can occur). For example, client write requests to the first consistency group may be rejected during snapshot creation, thus increasing latency and client data access disruption.